Managing Delegation in Access Control Models 
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Abstract 

In the field of access control, delegation is an impor- 
tant aspect that is considered as a part of the administra- 
tion mechanism. Thus, a complete access control must pro- 
vide a flexible administration model to manage delegation. 
Unfortunately, to our best knowledge, there is no complete 
model for describing all delegation requirements for role- 
based access control. Therefore, proposed models are often 
extended to consider new delegation characteristics, which 
is a complex task to manage and necessitate the redeflnition 
of these models. 

In this paper we describe a new delegation approach for 
extended role-based access control models. We show that 
our approach is flexible and is sufficient to manage all del- 
egation requirements. 



1. Introduction 

The delegation is the process whereby a user without any 
administrative prerogatives obtains the abihty to grant some 
authorizations. In the field of access control, defining con- 
cept of delegation is a difficult issue and only few works are 
dedicated to this point Il2l[3ll4l fill [131 . 

These works showed that delegation is a complex prob- 
lem to solve and is generally modeled separately from other 
administration requirements. The reason is that proposed 
models are generally based on the RBAC model |9| (Role- 
Based Access Control), which is not expressive enough to 
deal with delegation requirements such as temporary, par- 
tial, multi-step or multiple delegation. For instance, in the 
RBAC model, the only way to grant permission to a sub- 
ject is by granting this permission to a given role and then 
assigning this role to the subject. This is a rigid scenario, 
which does not adequately answer the need of fine-grained 
delegation. 



Therefore, it is necessary to extend the RBAC model by 
adding new components, such as new types of roles, per- 
missions and/or relations. This is a complex task to man- 
age, and to our best knowledge, there is no complete model 
for describing all delegation requirements. Thus, delegation 
models themselves are extended to consider new delegation 
characteristics. 

In this paper, we aim at proposing a flexible and com- 
plete delegation approach for role based access control. Our 
work is based on the OrBAC UJ (Organization based Ac- 
cess Control) formalism, which provides integrated frame- 
work to deal with various security requirements including 
delegation requirements. 

Namely, the OrBAC model gives means to specify con- 
textual authorizations, which facilitate the modeling of del- 
egation characteristics such as temporary delegation, cas- 
cading revocation, etc. In addition, in AdOrBAC [7| (Ad- 
ministration model for OrBAC) a large number of condi- 
tions can be expressed thanks to the use of views (in Or- 
BAC model a view is an access control entity used to put 
together objects to which apply the same authorizations, for 
more details see Q). 

This provides means to specify fine-grained delegation 
constraints, such as prerequisite conditions for the grantor 
(the user who performs the delegation) and the grantee (the 
user who receives the delegation). Therefore the adminis- 
trator can restrict the delegation by specifying delegation 
constraints that grantor and grantee must satisfy. 

This paper is organized as follows. In section 2 we start 
with basic concepts of the OrBAC and AdOrBAC models. 
In section 3 we present our delegation model. We discuss 
in section 4 the complexity and the decidability of our ap- 
proach. Then related work are given in section 5. Finally, 
concluding remarks are made in section 6. 



2. Basic concepts for OrBAC 

Before presenting our delegation model, we shall briefly 
recall the main components of OrBAC. 

2.1. OrBAC model 

The central entity in OrBAC is the entity organization. 
Intuitively, an organization is any entity that is responsible 
for managing a security policy. 

The objective of OrBAC is to specify the security policy 
at the organization level that is independently of the imple- 
mentation of this policy. 

Thus, instead of modeling the policy by using the con- 
crete concepts of subject, action and object, the OrBAC 
model suggests reasoning with the roles that subjects, ac- 
tions or objects play in the organization. 

The role of a subject is simply called a role, whereas the 
role of an action is called activity and the role of an object 
is called view. 

In OrBAC, there are eight basic sets of entities: Org (a 
set of organizations), S (a set of subjects), A (a set of ac- 
tions), O (a set of objects), R (a set of roles), A (a set of ac- 
tivities), V (a set of views) and C (a set of contexts). How- 
ever, for the sake of simplicity, we assume that the policy 
applies to a single organization and thus we omit the Org 
entity in the following. 

In the following we present the basic OrBAC builtin 
predicates: 

- empower is a predicate over domains SxR. If s a sub- 
ject and r a role, then empower{s, r) means that sub- 
ject s is empowered in role r. 

- use is a predicate over domains OxV. If o is an object 
and w is a view, then use{o, v) means that object o is 
used in view v. 

- consider is a predicate over domains AxA. If a is an 
action and a is an activity, then consider{a, a) means 
that action a implements the activity a. 

- hold is a predicate over domains SxAxOxC . If s 
a subject, a an action, o an object and c a context, 
hold{s, a, o, c) means that context c holds between 
subject s, action a and object o. 

- permission, prohibition and obligation are predicates 
over domains RgxAaxVoxC . Where Rs= RU S, Aa 
= AU A and Vo= V U O. More precisely, if 5 is a 
role or a subject, t is a view or an object and p is an 
activity or an action, then permission{g , p, t, c) (resp. 
prohibition{g,p, t, c) or obligaUon{g,p, t, c)) means 
that, grantee g is granted permission (resp. prohibi- 
tion or obligation) to perform privilege p on target t in 
context c. 



Since in the OrBAC model it is possible to spec- 
ify both permissions and prohibitions, some conflicts 
may occur. In prioritized OrBAC |5| the authorization 
rules are associated with priorities in order to evaluate 
their significance in conflicting situations. Then, pred- 
icates permission(g,p,t,c) and prohibition{g,p,t,c) 
are replaced by: permission{g,p,t,c,l) and 
prohibition{g,p, t, c, /), where I is the priority level. 

The OrBAC model is self administrated, that is the con- 
cepts used to define an administration policy are similar to 
the ones presented in this section. We give in the following 
section the basic concepts of the AdOrBAC model. 

2.2. AdOrBAC model 

The approach in AdOrBAC is to define administration 
functions by considering different administrative views. 
Objects belonging to these views have specific seman- 
tics; More precisely, we shall consider in the following 
two administrative views called rolejissignment and license 
views. They are respectively interpreted as an assignment of 
a user to a role in the rolejissignment view and a permission 
to a role or to a user in the license view. 

Intuitively, inserting an object in these views will enable 
an authorized user to respectively assign a user to a role, 
assign a permission to a role or assign a permission to a 
user Conversely, deleting an object from these views will 
enable a user to perform a revocation. 

Defining the administration functions in AdOrBAC then 
corresponds to specifying which role is permitted to have an 
access to administrative views. So that only valid licenses 
can be created. 

The AdOrBAC approach is homogeneous with the re- 
mainder of the OrBAC model. The syntax used to define 
permission to administer the policy is completely similar to 
the remainder of OrBAC. 

The two administrative views license and 
role -assignment are defined as follows: 

License view is used to specify and manage the security 
policy. Objects belonging to the license view have the fol- 
lowing attributes: grantee: subject to which the license is 
granted, privilege: action permitted by the license, target: 
object to which the license grants an access and context: 
specific conditions that must be satisfied to use the license. 

The existence of a valid license is interpreted as a per- 
mission by the following rule: 

permission{Sub, Act, Obj, Context):- 
use{L, license), grantee{L, Sub), 
privilege{L, Act), target{L, Obj), 
context{L, Context). 



Role_assignment view is associated with the following 
attributes: assignee: subject to which the role is assigned 
and assignment: role assigned by the role assignment. 

There is the following rule to interpret objects of the 
rolejassignment view: 

empower {Subject, Role):- 
use{RA, role-assignment) , 
assignee{RA, Subject), assignment(RA, Role). 

3 Delegation model 

We define in this section our delegation model. We show 
that the expressiveness of AdOrBAC is sufficient to manage 
delegation requirements without adding new components to 
the model. 

We present in this section the main delegation charac- 
teristics |2| like totality, permanence, monotonicity, lev- 
els of delegation, multiple delegation, cascading revocation, 
grant-dependency and show how to model them using the 
OrBAC formalism. 

The approach we suggest to manage delegation is the use 
of the notion of contexts and administrative views as defined 
in AdOrBAC. 

We define two administrative views: the li- 
cense .delegation view and the role -delegation view. 
These views are used, respectively, to delegate rights 
(partial delegation) and roles (total delegation) and they are 
defined as follows: 

permission{GR, A, O, C) :- 

use{L, license jdelegation), grantee{L, GR), 
privilege{L, A), target{L, O), context(L, C). 

empower{GR, Role) :- 

use{RD, role-delegation) , 

assignee{RD, GR), assignment{RD , Role). 

Objects belonging to these views have the same 
attributes, respectively, as the license view and the 
rolejissignment view but also have an additional attribute 
called grantor : the subject who is creating the license or 
the role. 

Inserting an object in the license delegation view or in 
the role -delegation view will enable a grantor to respec- 
tively delegate permission and role to a grantee. Therefore 
to manage delegation policy we must define which grantor 
(role or user) have an access to these views and in which 
context. This is defined by facts having the following form: 
permission{gr, delegate, licenseAelegation, context). 

permission{gr, delegate, role-delegation, context). 

To illustrate the approach, let us consider a situation 
where there are two users, John a professor and Mary his 
secretary. The role secretary is not generally permitted to 



have an access to the view stud-notes. However, John de- 
cides to delegate to Mary a permission to update his stu- 
dent's notes. Obviously, John must have a permission to 
delegate this right. 

For this purpose, the administrator should first create the 
following administrative view: 

use{L, notc-delegation):- 
use{L, license-delegation) , 
privilege{L, update), target{L, studjnotes). 

The view note -delegation is derived from li- 
cense-delegation view and only contains licenses to 
update student's notes. 

The administrator should then give to the role professor 
the permission to delegate licenses in this view: 

permission{prof, delegate, note-delegation, nominal). 
where nominal represents the default context. 

Using this permission, John can delegate to Mary a per- 
mission to update his student's notes by creating a new 
license Li, in the note -delegation view, with the follow- 
ing attributes: grantee: Mary, privilege: update, target: 
John_stud_notes (which is a sub-view of stud-notes) and 
context: nominal. As a result, the following permission is 
created: 

permission{mary, update, john stud -notes, nominal). 

Notice here that John can delegate the permission to up- 
date the view Johnstudjiotes because this is a sub_view of 
stud-notes. 

Therefore we assume that if the grantor have the permis- 
sion to delegate the license L then he also have the permis- 
sion to delegate a license U , which is a subJicense of L. 

We shall now formally define different types of dele- 
gation parameters, namely permanence, monotonicity, lev- 
els of delegation, multiple delegation; cascading revocation 
and grant dependent revocation. For this purpose, we need 
define the following predicate to verify if the license L is a 
subJicense of U: 
sub-License{L, L'):- 

target{L, T), target{L', T'), sub-target{T, T'), 
privilege{L, P),privilege{L' , P'), sub-priv{P, P'), 
context{L, G), context{L' , G'), sub-Context{G, G'). 

We consider (9 is a sub .target of (9 ' if there are two views 
and O is a sub_view of O', or if O is an object used in the 
view O ', or if they are equal. 

sub-target{0, O'):- 

sub-view{0, 0');use{0, O'); O = O' . 

Similarly, we define predicates sub-privilege and 
sub-Context. 

We also define the following predicate to verify if li- 
censes L and L' are equivalent: 

equivJicenses{L, L'): - 

sub-license{L, L'), sub-license{L' , L). 



3.1. Permanence 

Permanence refers to types of delegation in terms of their 
time duration. Indeed, in some circumstances, the delega- 
tion only applies temporarily and will be automatically re- 
voked after a given deadline. This may be modeled in our 
approach by simply using a temporal context. For further 
details about the context definition see f6\. 

In the previous example, there is no temporal specifica- 
tion of time duration in the context of delegation, so the 
delegation is permanent. Now if we assume that John wants 
to delegate to Mary the permission to update his student's 
notes only during his vacation, then he must specify this 
condition in the delegation context associated with the new 
license L2 he creates for Mary. The license L2 is similar 
to Li except that context = during John_vacation. The del- 
egated permission is specified as follows: 

permission{mary , update, john^studjnotes, 

during -johnjvacation). 

3.2. Monotonicity 

Monotonic delegation means that upon delegation the 
grantor maintains the permission he has delegated, as de- 
scribed in the example of previous sections. On the other 
hand, with a non-monotonic delegation, the grantor loses 
this permission for the duration of the delegation. 

To model non-monotonic delegation we define the li- 
cense Jransfer view as follows; 

use(L, licensejdelegation):- 
use{L, license-transfer). 

prohibition (Sub, Act, Obj, C, Max):- 
use{L, license-transfer), 
grantor(L, Sub) , privilege{L , Act), 
target{L, Obj), context{L, C). 

The license Jransfer view is a sub_view of the li- 
cense jlelegation view. So, inserting an object in this view 
will create a new permission to the grantee. In addition, it 
will create an interdiction to the grantor associated with the 
highest priority level Max. Therefore, the grantor will lose 
the permission he has delegated. 

Note that, the context of the prohibition and the dele- 
gated permission is the same one. So the grantor will lose 
this permission only for the time of the delegation. 

3.3 Multiple delegation 

Multiple delegation refers to the number of grantees to 
whom a grantor can delegate the same right at any given 
time. To control the delegation we assume that this num- 
ber (Nm) is fixed by the administrator using the context 



maxjnultijdelegation. In simple delegation case Nm is 
equal to 1 : 

permission{subject, delegate, view, context 

&z,maxjnultijielegation{Nm)). 

To define the context maxjnultijlelegation we need to 
count the delegation number concerning the same grantor 
and the same right: 

hold{S, A, L, max_multi_delegation(Nm)):- 
use{L, license-delegation) , 

grantor{L, S), count (L' , use{L' , license-delegation) , 
grantor (L' , S), equiv2icenses{L, L'), Nm'), 
Nm' <= Nm. 

We assume that count(V, p(V),N) is a predicate that count 
the set of instances of variable V that satisfies predicate 
p(V). N represents the result of the count predicate. 

Note that, we consider the licenses L and L' are the same 
right since they are equivalent. 

To explain this, let us consider the same roles of the pre- 
vious example. Suppose now we are in a simple delegation 
case, so that John can delegate the right to update his stu- 
dent's notes only for one time: 

permission{john, delegate, note-delegation, 

max -multi -delegation ( 1 ) ) . 

Thus, if John delegate to Mary the permission to up- 
date the view Johnstudentsjiotes, then John does not 
have the permission to delegate this right to another 
user. For instance, he cannot delegate the permission to 
update the file masterstudjiotes, which belongs to the 
view Johnstud-notes, to his assistant since this right is a 
sub Jicense of the first one. 

Notice that when the max-multi-delegation context is not 
used, the number of permissions a subject can delegate is 
not restricted. So this subject can delegate as many licenses 
he wants. 

3.4 Level of delegation 

This characteristic defines whether or not each delega- 
tion can be further delegated and how many times. 

For this purpose, we define the grantjoptionJicence 
view as follows : 

permission{U, delegate. Licence, C&zvalidJevel):- 
use{L, grant-option Jicense) , grantee{L, U), 
target{L, Licence), context{L, C). 

The context valid-level is defined as follows: 

hold(U, delegate, L, validJevel):- 

use{L' , grant-optionJicense) , subJicence{L', L), 
grantor{L', U),level{L, V),level{L', V'),V' < V. 

Objects belonging to the grantjoptionJicence view have 
an additional attribute called level: the number of autho- 
rized delegation steps. 



Inserting a license in this view will create a permission 
to the grantee to delegate the right but only in the context 
validjevel. 

This means that, if we consider the same license Li of 
the previous example and suppose that John wants to grant 
his secretary the permission to delegate this license with a 
delegation level equal to 3. 

For this purpose, John creates in the 
grant .optionJicence view the licence L3 with the fol- 
lowing attributes: grantee: Mary, privilege: delegate, 
target: Li, level: 3, context: nominal. 

This corresponds to the following rule: 

permission(mary , delegate, Li, validJevel). 

Therefore Mary can delegate the license Li (or a 
subJicense of Li) in the context validJevel, which means 
that she can create a license L4 to grant another user to del- 
egate this license and the delegation level of L4 must be 
lower than 3, since the delegation level of L3 is equal to 3. 

The grantor can also restrict the scope of the delegation 
using conjunctive context. For instance, John can specify, 
in the delegation context, that Mary can grant another user 
to delegate Li only during her vacation: 

permission(mary , delegate, LI, validJevel 

^during jrnary jvacation) . 

In this case, Mary can further delegate the license she 
receives from John but the delegated license will only apply 
in the context during J\lary_vacation. 

Note that we consider here only the monotonic and the 
partial delegation. The grant joptionJicence view is also 
used in the total delegation case (multi-step role delegation) 
and non_monotonic delegation case (multi-step transfer). A 
more detailed model will be proposed in future work. 

3.5 Revocation 

Revocation is an important aspect in delegation models. 
In this section we present some revocation properties 
and we plan to give a more detailed presentation in a 
forthcoming paper 

Grant Dependency In the case of GrantJDependent revo- 
cation (GD) only the grantor is allowed to revoke the dele- 
gated license or role. On the other hand. Grant Jndependent 
revocation (GID) allows any member in the sponsoring role 
to revoke the grantee. This is modeled using contexts: 

permissioniySubject, revoke, license jielegation, gd) . 

permission{subject, revoke, license jielegation, gid) . 

The gd and gid contexts are defined as follows: 

hold{U ser, revoke, L, gd):- 

use(L, license-delegation) , grantor {L , U ser). 



hold{U ser, revoke, L, gid):- 

use{L, license jielegation) , grantor [L , GR), 
empower(GR, Role), empower {User, Role). 
Contexts gd and gid are relevant for license revocation, 

we can similarly define gdr and gidr to revoke a role. 

Cascading revocation In multi-step delegation it is neces- 
sary to give the possibility to revoke indirectly the delega- 
tion chain. 

We can model this property thanks to the contextual li- 
cense: the delegation of right is valid only if the grantor still 
has this right. 

For this purpose we define the view cascad- 
ing jielegation, which is a sub_view of license jielegation 
view, as follows: 

permission{Sub, Act, Obj, CSzvalidjleleg{gr)):- 
use{L, cascading jielegation) , grantee{L , Sub), 
grantor(L, gr),privilege{L, Act), 
target{L, Obj), context{L, C). 

Inserting an object in this view will create a permission 
with an additional context (validjieleg context) which ver- 
ify if the grantor still has his right. 

This context is defined as follows: 

hold{U ser. A, O, validjieleg{gr)):- 
is-permitted[U ser, A,0). 

Therefore, the delegated permission is valid only if the 
delegation chain is maintained. 

Note that this property only concerns monotonic delega- 
tion. Other revocation aspects remain to be investigated in 
further work. 

4 Decidability and complexity 

The OrBAC model is based on first order logic and more 
precisely on Catalog 1.11 j which ensures a decidable and 
tractable theory. 

Catalog programs do not allow the use of functional 
terms and must only include both defined and safe rules. 
A rule is defined if every variable that appears in the con- 
clusion also appears in the premise. A rule is safe if it only 
provides means to derive a finite set of new facts. In pure 
Catalog program, rules do not contain any negative literal. 
Pure Catalog guarantees that any access control policy will 
be decidable in polynomial time. However pure Catalog 
expressivity is very restricted. 

In Catalog^, the negation restriction is relaxed. Nega- 
tive literals are allowed but rules must be stratified |ir|. 
A stratified Catalog^ program is computable in polynomial 
time. 

The definition of security policies using the OrBAC 
model obeys the Catalog^ restriction except the definition 
of contexts through the hold predicate. More precisely, the 



security rules correspond to ground close facts specified us- 
ing the permission, prohibition predicates. Specifications 
of predicates empower, use and consider correspond also to 
facts or rules that respect the Datalog^ restriction. 

By contrast, the definition of contexts does not corre- 
spond to Datalog^ restriction for the following reasons: 
these rules contain functional terms and are not always safe 
and defined. 

To solve these problems it is proposed firstly, to restrict 
the theory so that only relevant contexts are evaluated. A 
context is relevant if it appears in the definition of a security 
rule. Secondly, a relevant context is always fully instanti- 
ated. Finally it is proposed to pre-compute the evaluation of 
the Empower, Use and Consider predicates using a bottom- 
up strategy. Then, the evaluation of queries is completed 
using the top-down strategy as defined in the SGL algo- 
rithm |10|. This hybrid strategy guarantees the decidability 
of query evaluation in the OrBAC model and its termination 
in polynomial time. 

5 Related work 

The previous work on delegation has shown that delega- 
tion is a complex concept and, to our best knowledge, there 
is no complete model for describing all delegation charac- 
teristics such as multiple delegation, cascading revocation, 
etc. 

Proposed models are based on RBAC which is not ex- 
pressive enough to deal with the delegation requirements. 
To solve this problem it is suggested to extend the RBAC 
model to include delegation components, such as new types 
of roles, actions, permissions, etc. Unfortunately, this is a 
complex task to manage, since it is necessary to add new 
components for modeling every delegation characteristic. 

For instance, in the RBDMO model proposed by 121, 
authors extend RBACq model to define role-based delega- 
tion. They define a relation can-delegate C RxR to control 
role delegation and add new components such as: Users-O 
and Users-D to differentiate between original and delegated 
members, UAO and UAD to specify original member as- 
signment and delegate member assignment relations, etc. 

They also propose some extensions to RBDMO to ad- 
dress more delegations characteristics. This requires ad- 
ditional components. For instance they add new types 
of permissions: delegable and non delegable permissions 
(permissions-PN and permissions-PD) to model partial del- 
egation. 

In RBDMl 1 3 1, an extension of RBDMO, is proposed. 
This model adds new components such as a partially or- 
dered role hierarchy relation RH C Rx RXo model dele- 
gation using hierarchical roles. 

The PBDM model |fT3l is another delegation model 
based on RBAC96. This model uses the can-delegate re- 



lation with prerequisite condition to restrict delegates, and 
adds new types of roles and permissions to address permis- 
sion level delegation requirement. In PBDMO roles are par- 
titioned into regular roles (RR) and delegation roles (DTR). 
This partition induces a parallel partition of the two RBAC 
components: user-role assignment (UA) and permission- 
role assignment (PA). UA is separated into user-regular 
role assignment (UAR) and user-delegation role assignment 
(UAD). PA is similarly separated into permission-regular 
role assignment (PAR) and permission-delegation role as- 
signment (PAD). 

PBDMl is an extension to PBDMO which supports se- 
curity administrator involved delegation and revocation. 
This model adds new components such as delegatable 
roles (DBR), user-delegatable role assignment (UAB) and 
permission-delegatable role assignment (PAB). 

PBDM2 model is another extension which addresses 
a role-to-role delegation. Like other models, PBDM2 
adds new components, such as temporal delegatable roles 
(TDBR), and redefines existing ones. 

The ABDM model 1 12] is an attribute-based delegation 
model, which extend PBDM model to address delegation 
constraint. This model redefines the can-delegate relation to 
restrict the delegation. The ABDM model is also extended 
to ABDMa; for more flexibility. 

Another delegation model is proposed in f4^. This 
model is more complete than previous works. But it also ex- 
tends RBAC96 by adding new components to specify more 
delegation characteristics like temporary non-monotonic 
delegation. It introduces the relations: can-delegate and 
can-receive to authorize role delegation, and the relations 
can-delegatep and can-receivep to authorize permission del- 
egation. Also, it defines actions like xferRo, xferPo, xferPi, 
etc, to model roles and permissions transfer. The two rela- 
tions tempUA and tempPA are introduced to record tempo- 
rary user-role and user-permission delegations. 

Like the above discussed works, this model introduces 
new relations or actions to model each delegation charac- 
teristics. This is a complex task to manage especially when 
the delegation model has to be enriched. 

Compared to these works, our model is more flexible, 
simpler to manage and more complete. Indeed, OrBAC 
model offers facilities to deal with delegation requirements 
without the need for additional components. 

Namely, OrBAC model is based on multi-granular and 
contextual licenses. This provides facilities to define many 
delegation characteristics like totality, permanence, revoca- 
tion, etc. 

Moreover, thanks to the use of views we can express a 
large number of conditions, which allow us to specify del- 
egation constraints; This is modeled by prerequisite con- 
ditions associated with the grantee or the grantor. For in- 
stance, the professor is permitted to delegate a permission 



to manage her courses to her assistant but only if this assis- 
tant is a graduate student. 

6 Conclusion 

In this paper, we have proposed a new delegation ap- 
proach for role-based access control. We have showed that 
it is possible to specify delegation requirements using the 
OrBAC formalism. This model is self administrated and of- 
fers facilities, such as multi-granular license, contextual li- 
cense, use of views, etc., which gives means to specify del- 
egation characteristics without adding new components or 
modifying the exiting ones. Therefore our approach is more 
flexible, simpler and more complete than previous works 
based on RBAC model. 

The future work will be dedicated to enrich our delega- 
tion model and more precisely the revocation mechanism. 
We intend to include several of the revocation schemes as 
described in ||8|| . 
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